Open data protocol (OData) can be regarded as structured query language (SQL) for a web-based request environment. The number of possible OData requests for a specific OData service is very high and grows with increasing numbers of model entities and features that the OData standard defines, specific runtimes that OData supports, and specific features that the specific runtimes support. In using OData, there are usually a large variety of available data sources that differ in both structure and behavior and the selection of a best matching data source for a single OData request is typically based on affected model entities and request parameters. Therefore, implementing an OData service means that many combinations of affected model entities and different query options need to be handled. Although all possible combinations do not need to be supported by each OData service (or at least a fallback is available to a less efficient, but working, generic implementation is possible), it is important, for at least efficiency reasons, to maintain an overview of which requests a particular OData service implementation can support. The maintenance of a particular overview, however, typically leads to high complexity, a need to define and enforce structures associated with the particular OData service implementation, additional cost, and/or unnecessary use of business resources.